Fix: fold simulated device logs into HostLogger - #2061

No actionable comments were generated in the recent review. 🎉

sequenceDiagram
  participant device_runner
  participant AICPU_sim_device_log
  participant HostLogger
  device_runner->>AICPU_sim_device_log: set_host_log_state(state)
  AICPU_sim_device_log->>HostLogger: bind_state(state)
  device_runner->>AICPU_sim_device_log: set_log_level(level)
  AICPU_sim_device_log->>HostLogger: set_level(level)
  AICPU_sim_device_log->>HostLogger: vlog(level, message)

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

I pushed one commit on top of yours (a02ac3f7a) rather than only commenting, since the fix is small and has a failing repro. Squash or drop it as you see fit — your 04a920a43 is untouched.

First, a correction to my review. I said this PR introduced the duplicated file sink. It does not. host_log.cpp is already compiled into _task_interface, libcpu_sim_context.so, the sim host/AICore SOs, and every generated orchestration SO (cmake/host_log_sources.cmake + kernel_compiler.py:290), and each copy has its own host_log_file_sink(). The orchestration SO logs and is dlopened, so the hazard predates this change. What your PR does is add one more instance on a high-traffic SO that DeviceRunner::unload_executor_binaries() dlcloses at every teardown.

The defect. HostLogFileSink held a raw FILE* with no destructor. dlclose unmaps the 1 MiB stdio buffer without flushing it, so a module's pending records die with its mapping. Only WARN and above write through, which makes DEBUG/INFO/TIMING — the bulk of sim AICPU traffic — exactly what is lost whenever a bound output_prefix sends records to the file.

Measured with a consumer .so emitting 200 INFO records, then unloaded, deterministic across repeats:

The fix is a destructor on the sink (+13 lines). dlclose does run a function-local static's destructor, so the tail lands on disk. It closes only a stream this process opened — an inherited one holds records the parent still owns, and flushing that copied buffer would duplicate them, which is the invariant write_log_file already protects.

Also included:

• test_host_log_dso_unload + a small consumer .so. Verified it fails at 159/200 with the fix reverted, per discipline.md §3. Named to avoid colliding with Fix: make host logging nonblocking and unify sim output #2029's test_host_log_cross_dso.
• A missing case in test_sim_device_log: bind_level() clears log_directory_bound every time, so the sim file path had no coverage at all. Note this one passes with or without the fix — a single binary cannot observe a cross-DSO unload; it closes the destination gap, not the defect.
• The six stale spots in docs/logging.md — most importantly :136-138, which still told readers that folding sim's logger in "is tracked separately by issue [Code Health] Log subsystem — one clock, one grammar, one gate #1792 item 5", i.e. described your change as outstanding work. Plus a paragraph in host-trace.md: it described the buffering as per process, and it is per module, which is what makes unload observable.

On CI. The ut failure on a02ac3f7a is not from either of our commits. It is tests/ut/cpp/a2a3/test_hbg_submit_poison.cpp failing to compile against OrchestratorState::fatal / SharedMemoryHeader::orch_error_code after the src/common/host_build_graph/ relocation — a file neither of us touches. I confirmed by building your commit alone merged with current main (clean) and by checking out pure upstream/main (bf68bb6cf), where test_hbg_graph_submit_failure fails identically with nothing from this PR present. I have re-run the failed jobs against current main.

One thing worth your call: the destructor fix is arguably not item-5 work — it repairs a pre-existing hazard that this PR makes materially worse. If you or a maintainer would rather it land against main independently and get its own CI signal, the commit is self-contained and cherry-picks cleanly.